Contrôle MQTT en direct

astuce

Le contrôle MQTT en direct est destiné à un contrôle en direct. Pour l'envoi de programmes à l'avance, voyez Contrôle MQTT planifié à la place.

Ce guide vous aidera à configurer MQTT sur votre SmartgridOne Controller pour contrôler et surveiller à distance les installations de batteries et de panneaux solaires.

Ce dont vous avez besoin

SmartgridOne Controller avec connectivité Internet.
Identifiants MQTT : Cela peut être demandé en envoyant un e-mail à support@eniris.be.
Environnement de développement Python (ou tout autre client MQTT). Ce guide utilise un exemple de base écrit en Python pour vous aider à démarrer avec MQTT et l'envoi de commandes. Nous recommandons l'utilisation de Python pour sa facilité d'utilisation, mais tout autre client MQTT est pris en charge.

Informations supplémentaires

MQTT est un protocole de communication rapide sur Internet. C'est un système de messages publication/abonnement, qui permet une connexion directe entre votre machine et le SmartgridOne Controller. Vos actifs sont classés en groupes de solaire, de batterie, de véhicule électrique (EV) et de CVC.

Configuration initiale (Point de départ pour les nouveaux utilisateurs)

J'ai un SmartgridOne Controller que j'aimerais configurer pour le contrôle à distance MQTT.

1. Vérifiez votre réseau

Assurez-vous que votre réseau autorise le trafic MQTT sur le port 1883. Vous pouvez le faire en utilisant la commande :

nc -zv mqtt.eniris.be 1883

Lorsque cette commande n'est pas disponible, vous pouvez alternativement télécharger et exécuter ce code python.

En cas de doute, consultez votre ingénieur réseau ou utilisez temporairement le point d'accès 4G/5G de votre téléphone lorsque des erreurs de connexion se produisent.

remarque

Lorsque le port 1883 n'est pas accessible depuis votre réseau, nous proposons un secours sur le port 80. Cela peut être configuré dans votre client MQTT à une étape ultérieure de ce manuel.

2. Ajoutez vos appareils

Connectez-vous à l'interface de mise en service et assurez-vous que les dispositifs sont ajoutés à votre SmartgridOne Controller.

3. Ajoutez le signal externe MQTT

4. Activez le signal à distance MQTT

Le champ 'ID VPP' doit rester vide.

Le délai d'expiration du mécanisme de secours indique au SmartgridOne Controller combien de temps il doit attendre de nouvelles commandes. Lorsque le SmartgridOne Controller cesse de recevoir des commandes, il adopte automatiquement la stratégie par défaut après ce délai.

Ensuite, sélectionnez tous les appareils que vous souhaitez inclure dans le contrôle à distance MQTT.

5. Le signal à distance est ajouté

L'interface de contrôle à distance MQTT a maintenant été activée sur le SmartgridOne Controller.

Nous sommes maintenant prêts à envoyer quelques commandes de base en utilisant un exemple simple. La colonne État vous indique si une commande est active.

Script de démonstration Python

Un bon point de départ serait de tester votre intégration nouvellement configurée avec un exemple simple.

Ce code de test effectue un travail simple d'envoi continu des commandes suivantes :

Batterie : Charge à 5 kW
Solaire : Régler la puissance à 0 kW

Le SmartgridOne Controller répond continuellement avec un message de 'retour' contenant les valeurs observées de la grille et de l'énergie des actifs. Cette fonctionnalité est également incluse dans cet exemple.

Veuillez télécharger le fichier ci-dessous dans votre IDE Python préféré. Remplissez votre numéro de série et vos identifiants MQTT et exécutez le script :

Lorsque cela est réussi, vous pouvez continuer à envoyer d'autres types de commandes. Toutes les commandes sont décrites dans notre Documentation sur le contrôle à distance MQTT.

Documentation MQTT pour l'envoi de commandes

Cette section détaille le format de message MQTT et les exigences de charge utile pour contrôler à distance les politiques énergétiques sur les appareils au sein du réseau du SmartgridOne Controller.

Sujet MQTT

Le sujet MQTT utilisé pour envoyer des commandes est structuré comme suit :

standard1/rp_one_s/remoteControlMetrics/'controller SN'

Où 'controller SN' doit être remplacé par le numéro de série réel du SmartgridOne Controller que vous souhaitez contrôler.

Structure de la charge utile MQTT

Les commandes sont envoyées sous forme de charges utiles JSON. La structure de la charge utile est conçue pour spécifier diverses politiques de gestion de l'énergie et les points de consigne pour différents composants du système de réseau intelligent. Voici le schéma de la charge utile avec des descriptions détaillées des champs :

{
    "extraTags": {
        "nodeId": "<Controller SN>_site_0"
    },
    "time": "<Unix Timestamp>",
    "fields": {
        "<Composant Politique>": "<Type de Politique>",
        "<Point de Consigne de Puissance du Composant>": <Point de Consigne en watts>
    }
}

Description des champs

astuce

Plusieurs types de dispositifs (par exemple, batteries + solaire) peuvent être contrôlés en même temps.

extraTags (Objet) :
- nodeId (Chaine) : Un identifiant unique pour le nœud au sein du réseau du SmartgridOne Controller. Cela équivaut à votre numéro de série, suivi de '_site_0' pour la plupart des dispositifs SmartgridOne Controller.
time (Entier) : Timestamp Unix en secondes indiquant le moment où le message est envoyé.
fields (Objet) :
- <Composant>_policy (Chaine) : Type de politique pour le composant. C'est optionnel et si non spécifié, le système reviendra au paramètre par défaut du SmartgridOne Controller.
- <Composant>_power_setpoint_w (Flottant) : Point de consigne de puissance désirée en watts pour le composant. C'est optionnel et seulement pertinent si une politique correspondante est spécifiée.

Composants et Politiques

info

Les actifs du même type (par exemple, deux batteries) seront combinés en un seul composant. Par exemple, lorsque deux batteries de 5 kWh sont installées, elles seront considérées comme une seule batterie de 10 kWh.

Chaque composant dans l'objet fields peut inclure une politique et un point de consigne de puissance. Les composants suivants peuvent être contrôlés :

solar_policy et solar_power_setpoint_w :
- Contrôle de la politique de production d'énergie solaire et du point de consigne. Politiques supportées :
  - Point de consigne de politique : Régler la puissance maximale produite par toutes les installations solaires connectées combinées. Le champ solar_power_setpoint_w doit être réglé sur la limite de production en watts.
  - Politique de restriction d'alimentation : Produire à pleine puissance, en suivant les limites actuelles du réseau.
  - Politique de coût : Permet la minimisation des coûts des prix à jour (marché EPEX Spot) sur la production solaire. Lorsque des prix d'injection négatifs se produisent, nous limitons la production à la consommation propre. Lorsque le prix de prise et le prix d'injection sont négatifs, nous éteignons toutes les installations solaires. Le champ solar_power_setpoint_w est ignoré.
  - Politique off : Désactive toute interaction pour tous les actifs solaires. Avertissement : les limites ne sont pas surveillées dans ce mode. Le champ solar_power_setpoint_w est ignoré.
storage_policy et storage_power_setpoint_w :
Contrôle la politique du système de stockage d'énergie et le taux de décharge ou de charge de puissance.
- Point de consigne de politique : Définir la puissance totale de charge (point de consigne positif) ou la puissance de décharge (point de consigne négatif) pour le groupe de batteries. Lorsque plusieurs batteries sont connectées, le point de consigne est réparti par la puissance de charge/décharge disponible pour répartir également les contraintes sur les batteries. Le champ storage_power_setpoint_w est défini sur la puissance de batterie désirée.
- Coût de la politique : Permet l'optimisation des coûts du prix (marché de l'EPEX Spot) un jour à l'avance sur les batteries, en les chargeant pendant les heures bon marché et en utilisant l'énergie pendant les heures chères. Le champ storage_power_setpoint_w est ignoré.
- Politique d'autoconsommation : Permet un algorithme simple d'autoconsommation sur les batteries. La production solaire excessive est stockée dans la batterie pendant la journée, et lorsque le soleil est couché, l'énergie est prélevée sur la batterie. Le champ storage_power_setpoint_w est ignoré.
- Politique désactivée : Désactive toute interaction pour tous les actifs de batterie. Avertissement : les limites ne sont pas protégées dans ce mode. Le champ storage_power_setpoint_w est ignoré.
heat_pump_policy :
- Active/désactive les systèmes de pompe à chaleur. Les temps d'activation minimum et maximum seront toujours respectés.
  - Coût de la politique : Permet l'optimisation des coûts du prix (marché de l'EPEX Spot) un jour à l'avance sur les pompes à chaleur. L'algorithme de tarification dynamique local décide des meilleures périodes d'activation.
  - Politique d'autoconsommation : Active les pompes à chaleur si une quantité excessive d'énergie solaire est produite.
  - Politique d'arrêt : Éteint les pompes à chaleur.
  - Politique d'activation : Allume les pompes à chaleur.
switched_load_policy :
- Active/désactive les systèmes contrôlés par relais. Il peut s'agir du relais intégré ou de relais connectés au réseau.
  - Coût de la politique : Permet l'optimisation des coûts du prix (marché de l'EPEX Spot) un jour à l'avance sur le relais.
  - Politique d'autoconsommation : Active le relais si une quantité excessive d'énergie solaire est produite.
  - Politique d'arrêt
  - Politique d'activation
variable_power_load_policy et variable_power_load_power_setpoint_w :
- Gère la politique de consommation d'énergie des véhicules électriques et le point de consigne.
  - Point de consigne de politique : Définir la puissance totale de charge pour le groupe de VE. Le champ variable_power_load_power_setpoint_w est défini sur la puissance de charge désirée.
  - Coût de la politique : Permet l'optimisation des coûts du prix (marché de l'EPEX Spot) un jour à l'avance sur les batteries, en les chargeant pendant les heures bon marché. Le champ variable_power_load_power_setpoint_w est ignoré.
  - Politique d'autoconsommation : Permet la charge si une quantité excessive d'énergie solaire est produite. Le champ variable_power_load_power_setpoint_w est ignoré.
  - Politique désactivée : Désactive toute interaction pour tous les actifs de VE. Le champ variable_power_load_power_setpoint_w est ignoré.
site_policy et site_power_setpoint_w :
- Gère les limites d'exportation du site.
  - Politique d'exportation : Définir la limite d'exportation pour le site. Le champ site_power_setpoint_w est défini sur la limite d'exportation.
  - Politique par défaut : Rétablit la limite du site à la puissance d'exportation par défaut, définie dans la configuration du contrôleur.

Contrôle des appareils

Des appareils spécifiques peuvent également être contrôlés, au lieu de groupes d'appareils en fonction de leurs types. Le message est structuré de la même manière :

nodeId_policy et nodeId_power_setpoint_w

info

Lorsque deux commandes sont envoyées au même actif (par exemple, une commande spécifique à un appareil à un onduleur solaire, et une commande à tous les appareils solaires), la méthode de contrôle spécifique à l'appareil aura la préférence sur le contrôle par type d'appareil.

Comportement de secours

Pour chaque composant, si la _policy et _power_setpoint_w ne sont pas spécifiés, le système utilisera automatiquement la politique de secours configurée dans le SmartgridOne Controller. Cela garantit que chaque appareil ou groupe d'appareils fonctionne en toute sécurité et continue de fonctionner même si des instructions spécifiques ne sont pas fournies.

Si aucune commande n'est envoyée, après 60 secondes (ou période de timeout configurée), les politiques par défaut pour les actifs seront réactivées.

Exemple de charge utile

Voici un exemple d'une charge utile pour définir diverses politiques et points de consigne :

{
    "extraTags": {
        "nodeId": "OM12404080000000000_site_0"
    },
    "time": 1714652046,
    "fields": {
        "solar_policy": "setpoint",
        "solar_power_setpoint_w": 5000,
        "storage_policy": "setpoint",
        "storage_power_setpoint_w": -5000
    }
}

Dans cet exemple, la puissance solaire est réglée pour générer jusqu'à 5000 watts, et le système de stockage d'énergie est réglé pour charger ou décharger à un taux de 5000 watts, en fonction du signe de la valeur du point de consigne. Si la solar_policy ou la storage_policy étaient omises, le dispositif respectif reviendrait aux paramètres par défaut déterminés par le SmartgridOne Controller.

Documentation MQTT pour recevoir des retours

Cette section décrit la structure et le contenu des messages de retour envoyés par le SmartgridOne Controller via MQTT. Ces messages sont publiés sur le sujet standard1/outbound/remoteControlMetrics/feedback/<Controller SN> après qu'une commande a été traitée.

Sujet de retour MQTT

Le sujet de retour MQTT est structuré comme suit :

standard1/outbound/remoteControlMetrics/feedback/<Controller SN>

Où <Controller SN> doit être remplacé par le numéro de série du SmartgridOne Controller qui envoie le retour.

Structure de charge utile de retour MQTT

remarque

Tous les actifs sont regroupés par leur type. Cela signifie que deux installations solaires individuelles de 3 kW seront traitées comme un actif de 6 kW.

Les messages de retour sont formatés comme des charges utiles JSON. Ces charges utiles fournissent des retours détaillés sur l'état du système après l'application des commandes de point de consigne, en tenant compte des limites du réseau/appareil. Voici la structure de la charge utile de retour avec des descriptions de ses champs :

{
    "time": "<Unix Timestamp>",
    "data": {
        "state": {
            "grid": {
                "active_power_W": <Puissance Active du Réseau en Watts>,
                "today_imported_energy_Wh": <Énergie Importée Aujourd'hui en Watt-heures>,
                "today_exported_energy_Wh": <Énergie Exportée Aujourd'hui en Watt-heures>,
                "import_limit_W": <Limite d'Importation en Watts>,
                "export_limit_W": <Limite d'Exportation en Watts>
            },
            "vpp_id": "<Identifiant de la Centrale Électrique Virtuelle>",
            "storage": {
                "energy_stored_Wh": <Énergie Stockée en Watt-heures>,
                "energy_capacity_Wh": <Capacité Totale d'Énergie en Watt-heures>,
                "mean_soc_perc": <Pourcentage Moyen d'État de Charge>,
                "active_power_W": <Puissance Active en Watts>,
                "executed_power_W": <Point de Consigne de Puissance Envoyé aux Appareils en Watts>,
                "executed_policy": <Politique Exécutée par le Contrôleur>,
                "max_charge_power_W": <Puissance Maximale de Charge en Watts>,
                "max_discharge_power_W": <Puissance Maximale de Décharge en Watts>,
                "today_charged_Wh": <Énergie Chargée Aujourd'hui en Watt-heures>,
                "today_discharged_Wh": <Énergie Déchargée Aujourd'hui en Watt-heures>,
                "nr_devices": <Nombre d'Appareils de Stockage Contrôlés Installés>
            },
            "solar": {
                "active_power_W": <Puissance Active Solaire en Watts>,
                "executed_power_W": <Point de Consigne de Puissance Envoyé aux Appareils en Watts>,
                "executed_policy": <Politique Exécutée par le Contrôleur>,
                "capacity_W": <Capacité Solaire en Watts>,
                "today_energy_Wh": <Énergie Produite Aujourd'hui en Watt-heures>.
                "nr_devices": <Nombre de Dispositifs Solaires Contrôlés Installés>
            },
            "heat_pump": {
                "executed_policy": <Politique Exécutée par le Contrôleur>,
                "operation_modes": <Modes de Fonctionnement de la Pompe à Chaleur>,
                "executed_power_W": <Point de Consigne de Puissance Envoyé aux Dispositifs en Watts>,
                "nr_devices": <Nombre de Dispositifs de Pompe à Chaleur Contrôlés Installés>
            },
            "switched_load": {
                "executed_policy": <Politique Exécutée par le Contrôleur>,
                "devices_on": <Nombre de Dispositifs Allumés>,
                "devices_off": <Nombre de Dispositifs Éteints>,
                "executed_power_W": <Point de Consigne de Puissance Envoyé aux Dispositifs en Watts>,
                "nr_devices": <Nombre de Dispositifs de Charge Commutée Contrôlés Installés>  
            }
        },
        "response_code": <Code de Réponse>
    },
    "fields": {},
    "requestTime": "<Horodatage Unix>",
    "time": "<Horodatage Unix>",
    "siteNodeId": "<SN du Contrôleur>_site_0"
}

### Description des Champs
- time (Entier) : Horodatage Unix indiquant le moment où le message de retour a été envoyé.
- fields (Objet) :
    - state (Objet) :
        - vpp_id (Chaîne) : Identifiant de la Centrale Électrique Virtuelle associée à ce dispositif.
        - grid (Objet) :
            - active_power_W (Flottant) : Représente la puissance active actuelle sur le réseau en watts.
            - today_imported_energy_Wh (Flottant) : L'énergie totale prise du réseau aujourd'hui en watt-heures. Remarque : Aujourd'hui est donné en heure UTC.
            - today_exported_energy_Wh (Flottant) : L'énergie totale injectée dans le réseau aujourd'hui en watt-heures. Remarque : Aujourd'hui est donné en heure UTC.
            - import_limit_W (Flottant) : La limite d'importation du réseau en watts,
            - export_limit_W (Flottant) : La limite d'exportation du réseau en watts,
        - storage (Objet) :
            - energy_stored_Wh (Flottant) : Quantité actuelle d'énergie stockée en watt-heures.
            - energy_capacity_Wh (Flottant) : Capacité totale d'énergie du système de stockage en watt-heures.
            - mean_soc_perc (Flottant) : État de charge en pourcentage. C'est la moyenne pondérée parmi toutes les batteries connectées. (lorsque plusieurs batteries sont connectées : par exemple, la batterie 'a' a une capacité énergétique de 10 kWh et un état de charge de 20 % ; la batterie 'b' a une capacité énergétique de 20 kWh et un état de charge de 50 %, alors la mean_soc_perc est de 40 %)
            - active_power_W (Flottant) : Puissance active actuelle pour le système de stockage en watts, montrant le taux de charge ou de décharge.
            - max_charge_power_W (Flottant) : Puissance maximale à laquelle le stockage peut être chargé.
            - max_discharge_power_W (Flottant) : Puissance maximale à laquelle le stockage peut être déchargé.
            - executed_power_W (Flottant) : La somme de la puissance totale demandée pour (dé)charger les actifs de stockage, envoyée par notre algorithme de contrôle. Applicable uniquement si la politique 'follow_setpoint' est active.
            - executed_policy (Chaîne) : Les politiques qui ont été appliquées aux dispositifs contrôlables.
            - today_charged_Wh (Flottant) : L'énergie totale chargée dans les actifs de batterie contrôlables aujourd'hui. Remarque : Aujourd'hui est donné en heure UTC.
            - today_charged_Wh (Flottant) : L'énergie totale chargée dans les actifs de batterie contrôlables aujourd'hui. Remarque : Aujourd'hui est donné en heure UTC.
            - today_discharged_Wh (Flottant) : L'énergie totale déchargée des actifs de batterie contrôlables aujourd'hui. Remarque : Aujourd'hui est donné en heure UTC.
            - nr_devices (Entier) : Le nombre d'actifs de batterie contrôlables.
        - solar (Objet) :
            - active_power_W (Flottant) : Puissance active actuelle générée par les panneaux solaires en watts.
            - capacity_W (Flottant) : Capacité totale du système de génération solaire en watts.
            - executed_power_W (Flottant) : La somme de la puissance totale demandée des actifs solaires, envoyée par notre algorithme de contrôle. Applicable uniquement si la politique 'follow_setpoint' est active.
            - executed_policy (Chaîne) : Les politiques qui ont été appliquées aux dispositifs contrôlables.
            - today_energy_Wh (Flottant) : L'énergie totale produite par les actifs solaires contrôlables aujourd'hui. Remarque : Aujourd'hui est donné en heure UTC.
            - nr_devices (Entier) : Le nombre d'actifs solaires contrôlables.
        - heat_pump (Objet) :
            - executed_policy (Chaîne) : Les politiques qui ont été appliquées aux dispositifs contrôlables.
            - operation_modes (Chaîne) : Le mode de la pompe à chaleur (Mode de Blocage, Mode de Renforcement, Mode de Contrôle Autonome)
            - executed_power_W (Flottant) : La puissance attendue qu'elle utilise actuellement.
            - nr_devices (Entier) : Le nombre de pompes à chaleur contrôlables.
        - switched_load (Objet) :
            - executed_policy (Chaîne) : Les politiques qui ont été appliquées aux dispositifs contrôlables.
            - devices_on (Entier) : Le nombre de dispositifs allumés.
            - devices_off (Entier) : Le nombre de dispositifs éteints.
            - executed_power_W (Flottant) : La puissance qu'elle utilise actuellement (si disponible).
            - nr_devices (Entier) : Le nombre de charges commutées contrôlables sur/on.
        - nodeId (Objet) :
            - Si un nodeId est inclus dans la commande, le retour contiendra l'état correspondant du dispositif.
    - response_code (Entier) :
        - Indique le statut de l'opération. Un response_code de 0 signifie généralement un succès, tandis que d'autres valeurs peuvent indiquer différents types d'erreurs ou d'informations de statut (celles-ci doivent être détaillées dans une référence séparée).

### Exemple de Charge Utile de Retour
Voici un exemple de message de retour suite à une commande pour définir divers points de consigne de puissance :

<ClickableImage src="/img/generic/mqtt-example-feedback.png" alt="Image 1" maxWidth="450px" />

Ce retour démontre l'état opérationnel actuel du système suite à l'exécution des points de consigne, indiquant les effets sur la génération solaire, le stockage, et l'interaction globale avec le réseau.

## Versions MQTT Supportées et Comportement sur les Thèmes Non Autorisés
Lors de l'utilisation de MQTT, il est important de prendre en compte les différences dans les spécifications entre les versions 3.1, 3.1.1 et 5.0, notamment en ce qui concerne le comportement du broker lorsque les clients publient sur des thèmes non autorisés.

Selon la spécification MQTT 3.1.1 (voir OASIS MQTT 3.1.1 Specification, section MQTT-3.3.5-2), un broker doit terminer la connexion dès qu'un client envoie un PUBLISH à un sujet pour lequel il n'a pas l'autorisation. Ce comportement peut entraîner des déconnexions inattendues pour les clients essayant de publier sur des thèmes mal configurés ou non autorisés.

Dans MQTT 3.1, cette exigence n'est pas présente. Lorsqu'un client publie sur un sujet non autorisé sous cette version, le broker ignore généralement le message (rejet silencieux) sans terminer la connexion. Cela rend MQTT 3.1 dans certains cas plus adapté lorsque la robustesse contre les erreurs de configuration ou les autorisations temporairement manquantes est plus importante que l'application stricte de la sécurité.

Bien que MQTT 5.0 introduise la capacité de travailler avec des codes de raison (comme PUBACK avec un motif de refus), cela nécessite un support des deux côtés, client et serveur. La migration vers MQTT 5.0 implique donc un effort supplémentaire de mise en œuvre.

__Conséquences de l'Ignorance de la Compatibilité :__
Si un client se connecte en utilisant MQTT 3.1.1 et tente de publier des messages sur des sujets non autorisés, le courtier mettra brutalement fin à la session. Cela peut entraîner de l'instabilité, une perte de connectivité ou une charge accrue due à des tentatives de reconnexion répétées.

__Approche recommandée :__
Pour les systèmes où des clients peuvent (temporairement) tenter de publier sur des sujets non autorisés, ou lorsque la gestion des erreurs n'est pas strictement mise en œuvre, nous recommandons d'utiliser MQTT 3.1. Cela garantit des connexions plus stables et évite les déconnexions involontaires pendant l'exécution.

Ce dont vous avez besoin​

Informations supplémentaires​

Configuration initiale (Point de départ pour les nouveaux utilisateurs)​

1. Vérifiez votre réseau​

2. Ajoutez vos appareils​

3. Ajoutez le signal externe MQTT​

4. Activez le signal à distance MQTT​

5. Le signal à distance est ajouté​

Script de démonstration Python​

Documentation MQTT pour l'envoi de commandes​

Sujet MQTT​

Structure de la charge utile MQTT​

Description des champs​

Composants et Politiques​

Contrôle des appareils​

Comportement de secours​

Exemple de charge utile​

Documentation MQTT pour recevoir des retours​

Sujet de retour MQTT​

Structure de charge utile de retour MQTT​